1. Field of the Invention
The present invention pertains to wireless telecommunications, and particularly to handling TCP/IP connections which are transmitted over an air interface (e.g., radio link).
2. Related Art and Other Considerations
In a typical cellular radio system, mobile user equipment units (UEs) communicate via a radio access network (RAN) to one or more core networks. The user equipment units (UEs) can be mobile stations such as mobile telephones (“cellular” telephones) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by a unique identity, which is broadcast in the cell. The base stations communicate over the air interface (e.g., radio frequencies) with the user equipment units (UE) within range of the base stations. In the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
One example of a radio access network is the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The UMTS is a third generation system which in some respects builds upon the radio access technology known as Global System for Mobile communications (GSM) developed in Europe. A project known as the Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and Global System for Mobile communications (GSM)-based radio access network technologies.
UTRAN is essentially a radio access network providing wideband code division multiple access (WCDMA) to user equipment units (UEs). As those skilled in the art appreciate, in W-CDMA technology a common frequency band allows simultaneous communication between a user equipment unit (UE) and plural base stations. Signals occupying the common frequency band are discriminated at the receiving station through spread spectrum CDMA waveform properties based on the use of a high speed, pseudo-noise (PN) code.
There are several interfaces of interest in the UTRAN. The interface between the radio network controllers (RNCs) and the core network(s) is termed the “Iu” interface. The interface between a radio network controller (RNC) and its base stations (BSs) is termed the “Iub” interface. The interface between the user equipment unit (UE) and the base stations is known as the “air interface” or the “radio interface” or “Uu interface”. An interface between radio network controllers (e.g., between a Serving RNC [SRNC] and a Drift RNC [DRNC]) is termed the “Iur” interface.
The Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN) accommodates both circuit switched and packet switched connections. In this regard, in UTRAN the circuit switched connections involve a radio network controller (RNC) communicating with a mobile switching center (MSC), which in turn is connected to a connection-oriented, external core network, which may be (for example) the Public Switched Telephone Network (PSTN) and/or the Integrated Services Digital Network (ISDN). On the other hand, in UTRAN the packet switched connections involve the radio network controller communicating with a Serving GPRS Support Node (SGSN) which in turn is connected through a backbone network and a Gateway GPRS support node (GGSN) to packet-switched networks (e.g., the Internet, X.25 external networks).
As indicated above, packet switched data services can include Internet service. In terms of Internet connection, the transmission control protocol/Internet protocol (TCP/IP) has gained wide acceptance. Although usually functioning together, the internet protocol (IP) and transmission control protocol (TCP) are actually separate protocols, with the TCP being on a higher level (transport level) than the IP (on the network level). General concepts undergirding TCP/IP are understood from numerous publications, including Freeman, Telecommunication System Engineering, Third Edition, John Wiley & Sons, Inc., (1996), and W. R. Stevens, TCP/IP Illustrated, Volume I: The Protocols (Addison-Wesley, 1994).
In the Universal Mobile Telecommunications System (UMTS), a Radio Link Control (RLC) layer with its RLC protocol is interposed between a layer such as the Internet Protocol (IP) Layer and the Medium Access Control (MAC) layer. Radio link control (RLC) is a protocol layer that has various uses. The radio link control (RLC) has several modes of operation, including the transparent mode, the unacknowledged mode, and the acknowledged mode (AM). The mode of operation is selected according to the requirements of the higher layer. The radio link control (RLC) is used both for data flows and also for signaling flows.
FIG. 1 shows a Radio Link Control (RLC) layer 100 which transmits RLC PDUs (Protocol Data Units) to, and receives RLC PDUs from, the Medium Access Control (MAC) layer 102. In FIG. 1, the Medium Access Control (MAC) layer 102 functions as the “lower layer” relative to the RLC layer, while a TCP/IP layer 104 (e.g., IP layer) functions as the “higher layer”. The Medium Access Control (MAC) layer 102 is responsible, e.g., for mapping between logical channels and transport channels, priority handling, and scheduling of data flows on transport channels.
As shown in FIG. 1, an RLC entity 110-UE is provided in a user equipment unit (UE) and a RLC entity 110-RAN is provided in the UTRAN. With respect to the lower layer (e.g., Medium Access Control (MAC) layer 102), each RLC entity 110 has a transmitting side and a receiving side. With its RLC PDUs, the RLC protocol of the Radio Link Control (RLC) layer supports the in-sequence delivery of higher level Service Data Units (SDUs), which in the illustration of FIG. 1 are TCP/IP IP packets. The Radio Link Control (RLC) layer is described in more detail in 3GPP TS 25.322 V3.5.0 (200-12)3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification (Release 1999).
Data losses because of bit errors occur over conventional wired links, but such losses are so small as to be essentially non-existent (e.g., on the order of 10−6 over copper wire, and 10−9 over optical fiber). Such losses over conventional wired links stem almost exclusively from overflowing buffers in routers. TCP is designed to cope with these conditions, and consequently, packet losses are regarded as a congested network. Upon detection of loss, different implementations of TCP invoke different congestion avoidance mechanisms, but generally all such congestion avoidance mechanisms decrease the transmission speed.
Some limited code-type error recovery capability (e.g., convolutional coding) is provided over the air interface (i.e., radio interface). Over the air interface, such error recovery is performed locally with a local retransmission protocol, wherein all data in a transmission buffer is cached until it has been successfully delivered. In this regard, for example, the Radio Link Control (RLC) protocol of the Radio Link Control (RLC) layer has its local retransmission protocol—the Automatic Repeat Request (ARQ) protocol. The Automatic Repeat Request (ARQ) protocol of the RLC layer is used, e.g., to hide the stochastic block errors on the radio interface from the congestion avoidance algorithm of the TCP. In essence, using the ARQ retransmission protocol of the RLC layer, any lost data is quickly transmitted before TCP has a chance to detect the loss. By retransmitting the data locally (e.g., using the ARQ), faster recovery can be done and, most importantly, the TCP will not detect the loss and accordingly will not invoke the TCP congestion avoidance mechanism (unless data is lost somewhere other than over the air interface).
The consequence of the foregoing is that the loss rate of the Internet Protocol (IP) packets of TCP will be practically zero within the mobile access network. However, the TCP protocol will perceive variable packet delay depending on the conditions of the network (e.g., the loss rate of the RLC PDUs over the radio interface).
The third generation mobile networks seek generally to provide high birate for many types of applications. A typical example is the 384 kbit/sec bearer for best-effort (TCP) traffic. In a simulation concerning end-to-end performance of TCP over such a link, the average application level throughput (especially in the case of short files) was found to be far less than the physical level bit rate dedicated to the connection. This was primarily attributable to the relatively high delay IP packets suffer due to the acknowledging mechanism (e.g., ARQ) of the RLC. The control mechanism of TCP cannot work fast enough when it is probing the available bandwidth of the path. This leads to poor utilization of the radio bearer. Furthermore, increasing the bitrate of the bearer does not lead to improvement on the application level. Therefore, in this situation the only efficient means for improving the application level throughput is to lower the IP packet transaction delay.
The in-sequence delivery of TCP/IP IP packets, mentioned above, is important for the correct operation of TCP. The original order of the IP packets is determined on the receiving side of a RLC entity using the sequence numbers of the RLC PDUs and length indicator (LI) fields included in the RLC PDUs. The length indicator fields are employed, e.g., for making the SDU (e.g., TCP/IP IP packet) boundaries within the as RLC PDUs. The in-sequence delivery becomes even more important as the bitrate of the radio bearer increases, as (for example) in the case of the 384 kbit/sec bearer described above. With such radio bearer, one or more RLC PDUs carrying an IP packet can seem lost as RLC PDUs carrying subsequent IP packets arrive correctly. In this case, if the bitrate of the radio bearer is high and the round trip time (RTT) of the RLC PDUs is also high, many correctly arriving IP Packets can be blocked in the receiver's buffer because of a lost PDU belonging to an earlier IP packet. If the RTT is short compared to the transmission bandwidth, only a few IP packets can accumulate in the receiver.
In view of the foregoing, to avoid malfunction of the higher layers (e.g., the TCP/IP layer 104 in FIG. 1), even if an IP packet has completely arrived at the receiver side of the RLC entity, the RLC entity will not deliver the completely arrived IP packet to the higher layer (TCP/IP) unless all of the predecessor IP packets have already been delivered. Thus, the price of this in-sequence delivery is that the average delay in delivery of the IP packets increases significantly. In the case of one TCP connection over the RLC, the delay required to accommodate the in-sequence delivery occasions less performance degradation than would otherwise be experience by out-of-sequence delivery. However, this may not be the case in situations in which several TCP connections of one subscriber [e.g., one user of a user equipment unit (UE)] are operating over the RLC entity.
Recent investigations of Internet traffic reveal that Hypertext Transfer Protocol (HTTP)/1.0 is the most widely used transfer protocol for web browsing. A typical characteristic of Hypertext Transfer Protocol (HTTP)/1.0 is that it opens a new TCP connection for each embedded object (e.g., image) on a web page. Thus, a subscriber using Hypertext Transfer Protocol (HTTP)/1.0 to obtain a web page likely has several TCP connections extant when receiving the web page. The number of TCP connections can proliferate in the typical scenario in which a web user has open more than one web page at a time, e.g., as the user reads one web page while one or more other web pages are being download.
A buffer blocking problem is presented by the confluence of in-sequence delivery and the existence of multiple TCP connections. Conventionally, IP packets belonging to all of the multiple TCP connections are stored in a same RLC transmission is buffer. According to current specifications, it may easily occur that, due to one or more lost RLC PDUs belonging to a certain TCP connection, some other IP packets, belonging to other TCP connections, are blocked from delivery out of the common RLC transmission buffer (even though those other IP packets are in-sequence within their respective connections). This causes extra delay in the end-to-end IP packet transaction, and thus can significantly degrade TCP performance.
What is needed, therefore, and an object of the present invention, is a more efficient technique for providing in-sequence delivery of IP packets when plural TCP connections are opened by a subscriber.